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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The present document is part 2 of a muhi-part TS covering the 3''' Generation Partnership Project: Technical 
Specification Group Services and System Aspects, as identified below: 

Part 1: "3G Fault Management Requirements"; 

Part 2: "Alarm Integration Reference Point: Information Service"; 

Part 3: "Alarm Integration Reference Point: CORBA Solution Set; 

Part 4: "Alarm Integration Reference Point: CMIP Solution Set". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 

The present document is part of a set of TSs which describe the requirements and information model necessary for the 
Telecommunication Management (TM) of 3G systems. The TM principles and TM architecture are specified in 
3GPP TS 32.101 [6] and 3GPP TS 32.102 [7]. 

A 3G system is composed of a multitude of Network Elements (NE) of various types and, typically, different vendors 
inter-operate in a co-ordinated manner in order to satisfy the network users' communication requirements. 
The occurrence of failures in a NE may cause a deterioration of this NE's function and/or service quality and will, in 
severe cases, lead to the complete unavailability of the NE. In order to minimise the effects of such failures on the 
Quality Of Service (QOS) as perceived by the network users it is necessary to: 

• detect failures in the network as soon as they occur and alert the operating personnel as fast as possible; 

• isolate the failures (autonomously or through operator intervention), i.e. switch off faulty units and, if applicable, 
limit the effect of the failure as much as possible by reconfiguration of the faulty NE/adjacent NEs; 

• if necessary, determine the cause of the failure using diagnosis and test routines; and, 

• repair/eliminate failures in due time through the application of maintenance procedures. 

This aspect of the management environment is termed "Fault Management" (FM). The purpose of FM is to detect 
failures as soon as they occur and to limit their effects on the network Quality of Service (QOS) as far as possible. 
The latter is achieved by bringing additional/redundant equipment into operation, reconfiguring existing 
equipment/NEs, or by repairing/eliminating the cause of the failure. 
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Fault Management (FM) encompasses all of the above functionalities except commissioning/decommissioning of NEs 
and potential operator triggered reconfiguration (these are a matter of Configuration Management (CM), see [13]). 

FM also includes associated features in the Operations System (OS), such as the administration of alarm list, the 
presentation of operational state information of physical and logical devices/resources/functions, and the provision and 
analysis of the alarm and state history of the network. 
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1 Scope 



The present document defines the Alarm Integration Reference Point (IRP) Information Service (IS), which addresses 
the alarm surveillance aspects of Fault Management (FM), applied to the N Interface. 

The purpose of the AlarmlRP is to define an interface through which a "system" (typically a Network Element Manager 
or a Network Element) can communicate alarm information for its managed objects to one or several Manager Systems 
(typically Network Management Systems). 

The Alarm IRP IS defines the semantics of alarms and the interactions visible across the reference point in a protocol 
neutral way. It defines the semantics of the operations and notifications visible in the IRP. It does not define the syntax 
or encoding of the operations, notifications and their parameters. 



References 



The following documents contain provisions, which through reference in this text constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

[I] ITU-T Recommendation Q821: "Stage 2 and Stage 3 description for the Q3 interface - Alarm 
surveillance". 

[2] ITU-T Recommendation X.733 (02/92): "Information technology - Open Systems Interconnection 

- Systems management: Alarm Reporting Function". 

[3] ITU-T Recommendation X.721: "Information Technology - Open Systems Interconnection - 

Structure Of Management Information: Definition Of Management Information". 

[4] GSM 12. 1 1 version 6.2.0 Release 1997: "Fault management of the Base Station System (BSS)". 

[5] 3GPP TS 32.302: "Notification IRP: Information Service". 

[6] 3GPP TS 32. 101 : "3G Telecom Management principles and high level requirements". 

[7] 3GPP TS 32. 102: "3G Telecom Management architecture". 

[8] 3GPP TS 32.300: "Name Convention for Managed Objects". 

[9] 3GPP TS 32.111-1: "3G Fauh Management". 

[10] 3GPP TS 32.620-2: "Generic Network Resource Model (NRM)". 

[II] ITU-T Recommendation M.3100 (07/95): "Generic network information model". 
[12] ITU-T Recommendation X.720: "Management Information Model". 

[13] 3GPP TS 32.620-2 : "Generic Network Resources IRP : Network Resource Model". 

[14] 3GPP TS 32.312 : "Generic IRP Management : Information Service". 

[15] ITU-T Recommendation X.736: "...". 
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3 Definitions and abbreviations 

3.1 Definitions 

In addition to the terms and definitions defined in 3GPP TS 32.111-1 [9], the following definitions apply to this 
document: 

Event: It is an occurrence that is of significance to network operators, the NEs under surveillance and Network 
Management applications. Events do not have state. 

IRPManager: defined in 3GPP TS 32.102 [7]. 

IRP document version number string: The IRP document version number (sometimes called "IRPVersion") string is 
used to identify a particular IRP solution set specification. It is derived using the following rule. Take the 3GPP 
document version number on the front page of the solution set specification, such as "3GPP TS 32.106-3 V3.2.0 (2000- 
12)". Discard the leading "3GPP TS ". Discard all characters after and including the last period. Eliminate leading and 
trailing spaces. Reduce multiple consecutive spaces with one space. Express the resultant in a string. Capitalised the 
string. For example, if the 3GPP document version number is "3GPP TS 32.106-3 V3.2.0 (2000-12)", then the IRP 
document version number shall be "32.106 V3.2". 

Matching-Criteria-Attributes: It identifies a set of ITU-T Recommendation X.733 [2] defined attributes. 
Notifications carrying identical values for these attributes are considered to be carrying alarm information related to (a) 
the same network resource and (b) the same alarmed condition. The matching-criteria-attributes are: 

object Instance, eventType, probableCause and specif icProblem, if present. 

Notification: It refers to the transport of events from IRP Agent to IRPManager. In this IRP, notifications are used 
to carry alarm information from IRPAgent to IRPManager. 

IRP Agent: defined in 3GPP TS 32.102 [7]. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CCITT The International Telegraph and Telephone Consultative Committee 

CMIP Common Management Information Protocol 

DN Distinguished Name 

EM Element Manager 

IOC Information Object Class 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

MO Managed Object 

MOC Managed Object Class 

MOI Managed Object Instance 

NE Network Element 

NM Network Manager 

OS Operations System 

OSI Open System Interconnection 

RDN Relative Distinguished Name 

SS Solution Set 

UML Unified Modelling Language 

4 Basic aspects 
4.1 Background 

Integration Reference Points (IRPs) are the means within 3G Telecom Management (TM) for specifying interoperable 
points of information exchange between systems and applications. 
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3GPP TS 32.101 [6] and 32.102 [7] contain background and introductory information about the IRP concept. 



4.2 System Overview 



The following figures identify system contexts of this document in terms of implementations called IRP Agent and 
IRPManager. 

"IRPManager" depicts a process that interacts with IRPAgent for the purpose of receiving alarms via this IRP. 
Examples of IRPManager can be Network Management Systems and Alarm viewing devices (such as a local craft 
terminal). IRPAgent implements and supports the Alarm IRP. 

IRPAgent can be one Network Element (NE) (see figure 2) or it can be one Element Manager (EM) with one or more 
NEs (see figure 1). In the latter case, the interfaces (represented by a thick dotted line) between the EM and the NEs are 
not subject of this IRP. Whether EM and NE share the same hardware system is not relevant to this document either. 
By observing the interaction across the Alarm IRP, one cannot deduce if EM and NE are integrated in a single system 
or if they run in separate systems. 

As indicated in figure 1 and figure 2, the subject document need to be complemented with the Notification IRP [5] (to 
allow IRPManager to subscribe to notifications issued by IRPAgent and (optionally) product-specific resource 
models describing the MOs maintained by the IRPAgent). 
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Figure 1 : System Context A 
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Figure 2: System Context B 
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5 Information Object Classes 

5.1 Information entities imported and local label 



Label reference 


Local label 


32.302 [5], information object class, NotificationIRP 


NotificationIRP 


32.302 [5], interface, notif icationlRPNotif ication 


notificationlRPNotification 


32.620-2 [10], information object class, IRPAgent 


IRPAgent 


32.620-2 [10], information object class, ManagedGenericIRP 


ManagedGenericIRP 



5.2 Class diagram 



This sub-clause introduces the set of information object classes (lOCs) that encapsulate information within the 
IRPAgent. The intent is to identify the information required for the AlarmlRP Agent implementation of its operations 
and notification emission. This sub-clause provides the overview of all support object classes in UML. Subsequent 
sub-clauses provide more detailed specification of various aspects of these support object classes. 
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5.2.1 Attributes and relationships 



«lnformationObjectClass» 
AlarmlRP 



#identifyAlarmObject 



«lnformationObjectClass» 
MonitoredEntity 



relation-Alarm edObject- 
— I Alarm Information 



1..* 
ffidentifyAlarmIRP 



0..1 
#identifyBacl^UpObject 



relation 
Ala 



rm 



BackUpObject- 
Information 



#theBackUpObject 



#thealarm Information 



relation-Alarm Information-Correlated 
Notification 

#identifyCorrelatedNotificaticMl' 0..* 



«lnformationObjectClass» 
CorrelatedNotification 

# source 

# notificationldSet 



#identifyAarm Information 

0..* 

«lnformationObjectClass» 
Alarmlnformation 



# alarm Id 

# notificationid 

# alarmRaisedTime 

# alarmClearedTime 

# alarmChangedTime 

# eventType 

# probableCause 

# perceivedSeverity 
#specificProblem 

# backedUpStatus 

# trendlndication 

# thresholdlnfo 

# stateChangedDefinition 

# monitoredAttributes 

# proposedRepairActions 

# additionalText 

# ackTime 

# ackUserld 

# ackSystemId 

# ackState 



relation-Alarrr, IRP-AlarmList 

#identifyAlarmList 
1 
«lnformationObjectClass» 
Alarm Li St 

#theAlarm Information 

relation-Alarm List-Alarm Information 

#identifyAlarm Information 
< 



0..* 

#theAlarm Information 
relation-Alarm Information-Comment 



#identifyComments 

'«lnformationObjectClass» 
Comment 




#commentTime 
#commentText 
#commentUserld 
# commentSystemID 
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5.2.2 Inheritance 



Imported classes 



«lnterface» 
NotlficationlRPNotification 




«lnterface» 
AlarmlRPNotifications 1 




«lnterface» 
AlarmlRPNotification 2 



«lnformationObjectClass» 
ManagedGenericIRP 



# IRPVersions 

# operationNameProfiles 

# operationParameterProfiles 

# notificationNameProfiles 

# notificationParameterProfiles 



«lnformationObjectClass» 
AlarmlRP 



«lnterface» 
AlarmlRPNotification 3 



5.3 Information Object Class Definitions 

5.3.3 Alarmlnf ormation 
5.3.1.1 Definition 

Alarmlnf ormation contains information about alarm condition of an alarmed MonitoredEntity . 

One IRP Agent is related to at most one AlarmList. The IRPAgent or its related AlarmlRP or the related 
AlarmList assigns an identifier, called alarmld, to each Alarmlnf ormation in the AlarmList. An 
alarmld unambiguously identifies one Alarmlnf ormation in the AlarmList. 



5.3.1.2 



Attribute 



Attribute name 


Support Qualifier 


alarmld 


M 


notif icationid (note 1) 


M 


alarmRaisedTime 


M 


alarmClearedTime 


M 


alarmChangedTime 


O 


eventType 


M 


probableCause 


M 


perceivedSeverity 


M 


specif icProblem 


O 


backedUpStatus 


O 


trendlndication 


O 


thresholdlnfo 


o 


stateChangedDef inition 


o 


monit or edAt tributes 


o 


proposedRepair Act ions 


o 


additional Text 


o 
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ackTime 


M 


ackUserld 


M 


ackSystemId 


O 


ackState 


M 



Note 1 : This attribute may be "retired/removed" in Release 5 when Log IRP is introduced. Its removal implies that 
information carried in this attribute is no longer made accessible to IRPManager via the getAlarmListQ. 



5.3.1.3 



State diagram 



Alarms have states. The alarm state information is captured in Alarmlnformation inAlarmList. 

The solid circle icon represents the Start State. The double circle icon represents the End State. In this state, 
the alarm is Cleared and acknowledged. The Alarmlnformation shall not be accessible via the IRP and is removed 
from the AlarmList. 

Note the state diagram uses " X / Y '^ Z " to label the arc that indicates state transition. The meanings of X, Y and Z 
are: 

• X identifies the triggering event 

• Y identifies the action of IRP Agent because of the triggering event 

• Z is the notification to be emitted by IRP Agent because of the triggering event 

Note that acknowledgeAlarm'^notifyAckStateChanged and the 

unacknowledgeAlarm'^notifyAckStateChange refer to cases when the request of the IRPManager is 
successful for the Alarmlnformation concerned. They do not refer to the cases when the request is a failure 
since in the failure cases, no state transition would occur. 

Note that, to reduce cluttering to the diagram, the setCommenf^notif yComment is not included in the figure. One 
transition should be applied from unack&unclear to itself. Similarly, another transition should be applied from 
ack&unclear to itself. Another one is from unacks clear to itself. 

Note that "PS" used in the state diagram stands for "perceived severity". 
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"K 



The MO alarm's matching-criteria-attributes are not identical to the 
matchlng-crlteria-attributes of any Alarm Information in Alarm List. See appendix for 
the definition of matching-criteria-attributes. 



MO emits alarm / IRPAgent creates a 
new Alarm Information. '^notifyNewAlarm 



MO PS changes & new level is not 

cleared/& IRPAgent does not 

su|3port riotifyChangedAlarm 

'^notify GlearedAI arm , 

notify NewAlarm 




unack&unclear 



PS changes &pe\N level is 
not cleared & IRPAgent supports 
notilyQh^gedAlarm 
MO emits alkrm & IRPAgent\ ''notifyChangedAlarm 
supports notifyChangedAlarm 
'^notifyChangedAlarm 



_unacknowledgeAlarm 
'^notify AcRStateChange 




MO emits alarnrh&4RPAgent 

does notsupp^ 

notifyChangedAlarm" 

'^notifyClearedAlarm, 

notifyNewAlarm 



MO PS level changes to 
/ cleared 
AnotifyClearedAlarm 



acknowledgeAlarm 
^notifyAckStateChanged 



MO PS changes to 

cleared 
'^notifyClearedAlarm 




"K 



This is the terminal state (acknowledged and cleared). This 
Alarmlnformation no longer exists in the AlarmList. 
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5.3.2 



AlarmList 



5.3.2.1 



Definition 



IRPAgent maintains an AlarmList. It contains all currently active alarms (i.e. Alarmlnf ormation whose 
perceivedSeverity is not Cleared) and alarms that are Cleared but not yet acknowledged. 

5.3.2.2 Attribute 

There is no additional attribute defined for this IOC besides those inherited. 



5.3.3 



AlarmlRP 



5.3.3.1 



Definition 



AlarmlRP is the representation of the alarm management capabilities specified by this specification. This IOC 
inherits fromManagedCenericIRP IOC specified in [14]. 



5.3.4 



Comment 



5.3.4.1 Definition 

Comment contains commentary and associated information such as the time when the commentary is made. 

5.3.4.2 Attribute 



J Attribute Name 




commentTime 


M 


commentText 


M 


commentUserld 


M 


comment Systemid 


O 



5.3.5 



CorrelatedNotif ication 



5.3.5.1 Definition 

It identifies one MonitoredEntity. For that MonitoredEntity identified, a set of notification identifiers is also 
identified. One or more CorrelatedNotif ication instances can be related to an Alarmlnf ormation. In this 
case, the information of the Alarmlnf ormation is said to be correlated to information carried in the notifications 
identified by the CorrelatedNotif ication instances. See further definition of correlated notification in ITU-T 
Recommendation X.733 [2] clause 8.1.2.9. 

The meaning of correlation is dependent on the type of notification itself. See the comment column of the 
CorrelatedNotif ication input parameter for each type of notification, such as notif yNewAlarm. 

Notification carries Alarmlnf ormation. The Alarmlnf ormation instances referred to by the 
CorrelatedNotif ication may or may not exist in the AlarmList. For example, the Alarmlnf ormation 
carried by the identified notification may have been acknowledged and Cleared and therefore, no longer exist in the 

AlarmList. 
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5.3.5.2 Attribute 



Attribute Name 


Support Qualifier 


source 


M 


notif icationldSet 


M 



5.3.6 MonitoredEntity 



5.3.6.1 



Definition 



It encapsulates a subset of information of an IOC that can emit alarms. It can also encapsulate a subset of information 
of an IOC that serves as the back up object. 

5.3.6.2 Attribute 

There is no attribute for this IOC. 

5.4 Information relationships definition 

5.4.1 relation-AlarmlRP-AlarmList (M) 

5.4.1.1 Definition 

This represents the relationship between AlarmlRP and AlarmList. 



5.4.1.2 



Role 



Name 


Definition 


identifyAlarmIRP 


It represents the capability to obtain the identities of one or more AlarmlRP. 


identif yAlarmList 


It represents the capability to obtain the identify of one AlarmList. 



5.4.1.3 Constraint 

There is no constraint for this relationship. 

5.4.2 relation-AlarmList-AlarmInf ormation (M) 
5.4.2.1 Definition 

This represents the relationship between AlarmList and Alarmlnf ormation . 



5.4.2.2 



Role 



Name 


Definition 


theAlarmInf ormation 


It represents the Alarmlnf ormation. 


identifyAlarmlnformati 

on 


It represents a capability to obtain the information contained in 

Alarmlnf ormation. 
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5.4.2.3 Constraint 



Name 


Definition 


inv_ 
hasAlarmlnformationl 


No Alarmlnformation playing the role of theAlarmlnformation shall 
have its perceivedSeverity = "cleared" and its ackState = 
"acknowledged". 


inv_ 

hasAlarmInf ormation2 


The alarmld of all Alarmlnformation instances playing the role of 

theAlarmlnformation are distinct. 



5.4.3 relation-AlarmInf ormation-Comment (M) 
5.4.3.1 Definition 

This represents the relationship between Alarmlnformation and Comment . 



5.4.3.2 



Role 



Name 


Definition 


theAlarmlnformation 


It represents the Alarmlnformation. 


identifyComment 


It represents a capability to obtain the information contained in Comment . 



5.4.3.3 Constraint 

There is no constraint. 

5.4.4 relation-AlarmInf ormation-CorrelatedNotif ication 
(M) 

5.4.4.1 Definition 

This represents the relationship between Alarmlnformation and CorrelatedNotif ication . 



5.4.4.2 



Role 



Name 


Definition 


theAlarmlnformation 


It represents the Alarmlnformation. 


identifyCorrelatedNoti 
f ication 


It represents a capability to obtain the information contained in 

CorrelatedNotif ication. 



5.4.4.3 Constraint 

There is no constraint. 
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5.4.5 relation-AlarmedOb ject-AlarmInf ormation (M) 

5.4.5.1 Definition 

This represents the relationship between MonitoredEntity and Alarmlnf ormation. 

5.4.5.2 Role 



Name 


Definition 


identif yAlarme 
dObject 


It represents the capability to obtain the identification, in terms of object Class 
ob jectlnstance, of alarmed network resource. 


and 


identifyAlarmI 
nf ormation 


It represents the capability to obtain the identities of Alarmlnf ormation. 



5.4.5.3 Constraint 



Name 



Definition 



inv_relation- 
AI-ME 



All Alarmlnf ormation involved in this relationship with the same MonitoredEntity 
shall have at least one different value in the following attributes: eventType, 

probableCause and specif icProblem. 



5.4.6 relation-backUpObject-AlarmInf ormation (0) 

5.4.6.1 Definition 

The relationship represents the relationship between Alarmlnf ormation and the backUpOb ject. 

5.4.6.2 Role 



Name 


Definition 


identifyBackUpOb je 
ct 


It represents a capabiUty to obtain the identification, in terms of object Class and 
ob jectlnstance, of the backUpObject. 



5.4.6.3 Constraint 



Name 



Definition 



inv_identif yBa 
ckUpOb ject 



This relationship is present if and only if the Alarmlnf ormation. backedUpStatus 
attribute is present and is indicating true. 



5.5 Information attribute definition 
5.5.1 Definition and legal values 



Name 


Definition 


Legal Values 


alarmld 


It identifies one Alarmlnf ormation in the AlarmList. 




notification 
Id 


It identifies the notification that carries the 

Alarmlnf ormation . 




alarmRaised 


It indicates the date and time when the alarm is first raised by 


All values indicating valid time. 
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Name 


Definition 


Legal Values 


Time 


the alarmed resource. 




alarmChanged 
Time 


It indicates the last date and time when the 
Alarmlnf ormation is changed by the alarmed resource. 
Changes to Alarmlnf ormation caused by invocations of 
the IRPManager would not change this date and time. 


All values indicating valid time. 


alarmCleared 
Time 


It indicates the date and time when the alarm is Cleared. 


All values indicating valid time. 


eventType 


It indicates the type of event. See Annex A for information on 
event type. 


See Annex A. 


probableCause 


It qualifies alarm and provides further information than 
eventType. See Annex B for a complete Hsting. 


See Annex B. 


perceived 
Severity 


It indicates the relative level of urgency for operator attention. 


Critical, Major, 
Minor, Warning, 
Indeterminate, 
Cleared: see ITU-T 
Recommendation X.733 [2]. 
This IRP does not recommend 
the use of indeterminate. 


specific 
Problem 


It provides further qualification on the alarm than 
probableCause. This attribute value shall be single-value 
and of simple type such as integer or string. See definition in 
ITU-T Recommendation X.733 [2] clause 8.1.2.2. 


Provided by vendor. 


backedUp 
Status 


It indicates if an object (the MonitoredEntity) has aback 
up. See definition in ITU-T Recommendation X.733 [2] clause 
8.1.2.4. 


All values that carry the 
semantics of 

backedUpStatus defined by 
ITU-TX.733 [2] clause 8.1.2.4. 


trend 
Indication 


It indicates if some observed condition is getting better, worse, 
or not changing. 


"Less severe", "no change", 
"more severe": see definition in 
ITU-T Recommendation X.733 
[2] clause 8.1.2.6. 


thresholdlnfo 


It indicates the direction of threshold crossing. 


"Up direction", "down 
direction": see definitions in 
ITU-T Recommendation X.733 
[2] clause 8.1.2.7. 


stateChange 
Definition 


It indicates MO attribute value changes. See definition in ITU- 
T Recommendation X.733 [2] clause 8.1.2.10. 




monitored 
Attributes 


It indicates MO attributes whose value changes are being 
monitored. See definition in ITU-T Recommendation X.733 
[2] clause 8.1.2.11. 




proposed 
RepairActions 


It indicates proposed repair actions. See definition in ITU-T 
Recommendation X.733 [2] clause 8.1.2.12. 




additional 
Text 


It carries semantics that is outside the scope of this IRP 
specification. It may provide the identity of the NE (e.g. RNC, 
Node-B) from which the alarm has been originated. It 
corresponds to the "user label" attribute of the object class 
representing the NE in the Generic Network Resource Model 
[10]. 

It can contain further information on the alarm. 


N/A 


ackTime 


It identifies the time of last operation acknowledgeAlarms or 
unacknowledgeAlarms. 


All values that indicate valid 
time that are later than that 
caiiied in alarmRaisedTime. 
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Name 


Definition 


Legal Values 


ackUserld 


It identifies the last user who has change the Acknowledgement 
State via operation acknowledgeAlarms or 
unacknowledge Alarms . 

It can be used to identify the human operator such as "John 
Smith" or it can identify a group, such as "Team Six", or it can 
contain no information such as "". 


N/A 


ackSystemId 


It identifies the system in which IRPManager, that invokes 
the acknowledgeAlai-ms or unacknowledgeAlarms operation, 
runs. 


N/A 


ackState 


It identifies the Acknowledgement State of the alarm. 


Acknowledged: the alai'm has 
been acknowledged. 

Unacknowledged: the alarm has 
been unacknowledged or the 
alarm has never been 
acknowledged. 


commentTime 


It carries the time when a comment is made via setComment 
operation. 




comment Text 


It carries the textual comment made via setComment 
operation. 




comment User Id 


It carries the identification of the user who made the comment 
via setComment operation. 




comment System 
Id 


It carries the identification of the system in which the the 
IRPManager runs. That IRPManager supports the user that 
made the comment. 




source 


It identifies one MonitoredEntity. 


All values that carry the 
semantics of DN. 


notif icationi 
dSet 


It carries one or more notification identifiers. 





5.5.2 Constraints 



Name 



Definition 



inv_alarmChanged 
Time 



Time indicated shall be later than that carried in alarmRaisedlime. 



inv_alarmCleared 
Time 



Time indicated shall be later than that carried in alarmRaisedlime. 



inv_ackTime 



Time indicated shall be later than that carried in alarmRaisedlime. 



inv_notif ication 

Id 



Notif ication Ids shall be chosen to be unique across all notifications of a particular 
managed object (representing the NE) throughout the time that alarm correlation is 
significant. The algorithm by which alarm correlation is accomplished is outside the scope 
ofthisIRP. 
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Interface Definition 



6.1 Class diagram 



«lnformationObjectClass» 
AlarmlRP 



«lnterface» 
AlarmlRPOperations_1 



+ getAlarmList() 

+ acknowledgeAlarms() i 



«lnterface» 
AlarmlRPOperation_2 

+ getAlarmCountO 

«lnterface» 
AlarmlRPOperatio_3 

unacknowledgeAlarms 



«lnterface» 
AlarmlRPOperation_4 

+ setCommentO 




«lnformationObjectClass» 
Alarm List 



«lnterface» 
AlarmlRPNotifications_1 

+ notifyNewAlarm{) 
+ notifyAckStateChangedO 
+ notifyClearedAlarmO 
+ notifyAlarmListRebuiltQ 



«lnterface» 
Alarm IRPNotification 2 



0..1 



0..1 



+ notifyChangedAlarmO 



«lnterface» 
AlarmlRPNotification 3 



+ notifyCommentsO 



6.2 



Generic rules 



Rule 1 : each operation with at least one input parameter supports a pre-condition valid_input_parameter 
which indicates that all input parameters shall be valid with regards to their information type. Additionally, 
each such operation supports an exception operation_failed_invalid_input_parameter which is raised when 
pre-condition validjnput_parameter is false. The exception has the same entry and exit state. 

Rule 2: Each operation with at least one optional input parameter supports a set of pre-conditions 
supported_optional_input_parameter_xxx where "xxx" is the name of the optional input parameter and the 
pre-condition indicates that the operation supports the named optional input parameter. Additionally, each 
such operation supports an exception operation_failed_unsupported_optional_input_parameter_xxx which is 
raised when (a) the pre-condition supported_optional_input_parameter_xxx is false and (b) the named 
optional input parameter is carrying information. The exception has the same entry and exit state. 

Rule 3: each operation shall support a generic exception operation_failed_internal_problem that is raised 
when an internal problem occurs and that the operation cannot be completed. The exception has the same 
entry and exit state. 
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6.3 Interface AlarmIRPOperations_l 

6.3.1 acknowledgeAlarms (M) 
6.3.1.1 Definition 

The IRPManager invokes this operation to acknowledge one or more alarms. 



6.3.1.2 



Input Parameters 



Name 


Qua 
lifier 


Information Type 


Comment 


alarm 


M 


List of 


It carries one or more identifiers identifying 


Information 




Alarmln format ion. alarm 


Alarmlnf ormation instances in AlarmList. 


ReferenceList 




Id 




AckUserld 


M 


Alarmlnf ormation . ackUs 
end 


It identities the user acknowledging the alai-m. 


ackSystemId 


O 


Alarmlnf ormation . ackSy 


It identifies the processing system on which the subject 






stemid 


IRPManager runs. It may contain no information 
implying that IRPManager does not wish this 
information be kept in Alarmlnf ormation in 
AlarmList. 



6.3.1.3 



Output Parameters 



Name 


Qua 
lifier 


Matching Information 


Comment 


badAlarm 

Information 

ReferenceList 


M 


List of pair of 

Alarmln format ion. alarm 
I d and failure reason. 


If allAlarmsAcknowledged is true, it contains 
no information. 

If someAlarmAcknowledged is true, then it 

contains identifications of Alarmlnf ormation that 

are (a) present in input parameter 

Alarmlnf ormationReferenceList but are 

absent in the AlarmList; or 

(b) present in input parameter 

Alarmlnf ormationReferenceList and are 

present in the AlarmList but the Acknowledgement 

Information (see note below table) has not changed, in 

contrast to IRPManager's request. 


status 


M 


ENUM (OperationSucceeded, 
OperationFailed, 
OperationPartially S ucceeded) 


If someAlarmAcknowledged is true, status = 
Operation? artiallySuceeded. 

If allAlarmsAcknowledged is true, status = 
OperationSucceeded. 

If operation_failed is true, status = OperationFailed. 



Note: Acknowledgement Information is defined as the information contained in Alarmlnf ormation . ackTime, 
Alarmlnf ormation . ackUserld, Alarmlnformaton.ackSy stemid, Alarmlnf ormation . ackState. 

6.3.1.4 Pre-condition 

atLeastOneValidld. 



ETSI 



3GPP TS 32.111-2 version 4.0.0 Release 4 



24 



ETSI TS 132 111-2 V4.0.0 (2001-06) 



Assertion Name 



Definition 



at Least OneVali 
did 



The Alarmlnf ormationRef erenceList contains at least one identifier that identifies 
one Alarmlnf ormation in AlarmList and that this identified Alarmlnf ormation 
shall have its ackState indicating "unacknowledged". 



6.3.1.5 



Post-condition 



someAlarmAcknowledged OR allAlarmsAcknowledged. 



Assertion Name 


Definition 


someAlarmAckno 
wledged 


At least one but not all Alarmlnf ormation identified in input parameter 
AlarmlnformationReferenceList has been acknowledged. Acknowledgement of an 
Alarmlnf ormation means that the ackState attribute has been set to "acknowledged", that 
ackUserld, ackSystemId attributes of this Alarmlnf ormation have been set to the values 
provided as input pai'ameter and that the time of acknowledgeAlarms operation has been 
registered in ackTime attribute. 


allAlarmsAckno 
wledged 


All Alarmlnf ormation identified in input parameter have been acknowledged. 
Acknowledgement of an Alarmlnf ormation means that the ackState attribute has been set 
to "acknowledged", that ackUserld, ackSystemId attiibutes of this Alarmlnf ormation have 
been set to the values provided as input parameter and that the time of acknowledgeAlarms 
operation has been registered in ackTime attribute. 



6.3.1.6 



Exceptions 



, Name 




operation_f ailed 


Condition: Pre-condition is false or post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.3.2 getAlarmList (M) 



6.3.2.1 



Definition 



IRPManager requests IRP Agent to provide the list of Alarmlnf ormation instances in AlarmList. 

There are two modes of operation. One mode is synchronous. In this mode, the list of Alarmlnf ormation 
instances in AlarmList is returned synchronously with the operation. The other mode is asynchronous. In 
this mode, the list of Alarmlnf ormation instances is returned via notifications. In asynchronous mode of 
operation, the only information returned synchronously is the status of the operation. The mode of operation to be used 
is determined by means outside the scope of specification. To use asynchronous mode, the IRPManager must have 
established a subscription with the IRP Agent notificationIRP via the subscribe operation specified in [5]. 



6.3.2.2 



Input Parameters 



Name 


Quali 
fier 


Information Type 


Comment 


alarmAckSta 
te 


O 


ENUM (all alarms, all active 
alarms, all active and 
acknowledged alarms, all 
active and unacknowledged, all 
Cleared and unacknowledged 
alarms, all unacknowledged) 


It carries a constraint. The IRP Agent shall apply it on 

Alarmlnf ormation instances in AlarmList when 
constructing its output pai'ameter 

Alarmlnf ormationLi St. 


filter 


O 


N/A 


It carries a filter constraint. The IRPAgent shall apply it 
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on Alarmlnformation instances in AlarmList when 
constructing its output parameter 

AlarmlnformationList. 



6.3.2.3 



Output Parameters 



Name 


Qua 
lifier 


Matching Information 


Comment 


Alarmlnform 
ationList 


M 


List of Alarmlnformation. 


It carries Alarmlnformation in AlarmList. 

Case when synchronous mode of operation is used: 

(a) The I RP Agent shall apply the constraints 
expressed in alarmAckState and filter to 
Alarmlnformation instances when 
constructing this output parameter. 

Case when asynchronous mode of operation is used 
(i.e., this output parameter is conveyed via 
notifications): 

(a) If the filter parameter is present, the I RP Agent 
shall apply the constraint when constructing this output 
parameter. Furthermore, if the alarmAckState 
constraint is present, the IRP Agent shall apply that 
constraint as well. The filter constraint, if any, that is 
currently active in the notification channel is not used 
for the construction of this output parameter. 

(b) If the filter parameter is absent, the IRP Agent 
shall apply the filter constraint currently active in the 
notification channel when constructing this output 
parameter. If the alarmAckState constraint is present, 
the IRP Agent shall apply that constraint as well. 


status 


M 


ENUM (OperationSucceeded, 
OperationFailed) 


If allAlarmlnformationReturnedis true, 
status = OperationSucceeded. 

If operation_failedis true, status = 
OperationFailed. 



6.3.2.4 Pre-condition 

There is no pre-condition. 



6.3.2.5 



Post-condition 



allAlarmInf ormationReturned . 



Assertion Name 


Definition 


allAlarmInf ormati 
onReturned 


All Alarmlnformation that satisfy the constraints expressed in input parameters filter 
and alarmAckState and are present in the AlarmList at the moment of this operation 
invocation are returned. All Alarmlnformation in AlarmList remains unchanged 
as the result of this operation. 
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6.3.2.6 



Exceptions 



Assertion Name 


Definition 


ope rat ion_f ailed 


Condition: At least one input parameter is invalid or the pre-condition is false or the post- 
condition is not ture. 

Returned Information: The output parameter status. 
Exit state: Entry state. 



6.4 



Interface AlarmIRP0peration_2 



6.4.1 getAlarmCount (O) 



6.4.1.1 



Definition 



An IRPManager wishes to know the amount of Alarmlnf ormation kept in the AlarmList. The IRPManager 
requests the counts via this operation. Possible usage is for IRPManager to find out the number of 
Alarmlnf ormation in AlarmList before invoking getAlarmList operation. 



6.4.1.2 



Input Parameters 



Name 



Qua 
lifier 



Information Type 



Comment 



filter 



O 



N/A 



It carries a filter constraint. The operation shall apply it when 
counting the Alarmlnf ormation instances in AlarmList. 

Case when synchronous mode of operation is used for 

getAlarmList: 

(a) If this parameter is present, the operation shall count the 
Alarmlnf ormation instances which satisfy both (a) this filter 
constraint and (b) the condition set by input parameter 

alarmAckState. 

(b) If this parameter is absent, the operation shall count all 
Alarmlnf ormation instances that satisfy the condition set by 
input parameter alarmAckState. 

Case when asynchronous mode of operation is used for 

getAlarmList: 

(a) If this parameter is present, the operation shall count all 
Alarmlnf ormation instances that satisfy this filter constraint 
and the condition set by input parameter alarmAckState. 

(b) If this parameter is absent, the operation shall count 
Alarmlnf ormation instances that satisfy (a) the filter 
constraint currently active in the notification channel established 
between the IRPManager and the IRP Agent that is equipped 
with NotificationIRP capabilities and (b) the condition set by input 
parameter alarmAckState. 



alarmAckState 



O 



ENUM (all alarms, all 
active alarms, all 
active and 

acknowledged alarms, 
all active and 
unacknowledged, all 



It carries a constraint. The operation shall apply it on 

Alarmlnf ormation instances in AlarmList when counting 
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cleared and 
unacknowledged 
alarms, all 
unacknowledged) 





6.4.1.3 



Output Parameters 



Name 


Qua 
lifier 


Matching Information 


Comment 


criticalCount, 

ma jorCount, 

minorCount, 

warningCount, 

indeterminateC 

ount, 

clearedCount 


M 


N/A 


They carry the number of Alarmlnf ormation in AlarmList 
that has the following properties. 

Case when synchronous mode of operation is used: 

(a) The operation shall apply the constraints expressed in 
alarmAckState and filter to Alarmlnf ormation instances 
when counting. 

Case when asynchronous mode of operation is used (i.e., this 
output parameter is conveyed via notifications): 

(a) If the filter parameter is present, the operation shall apply the 
constraint when counting. Furthermore, if the alarmAckState 
constraint is present, the operation shall apply that constraint as 
well. The filter constraint, if any, that is currently active in the 
notification channel is not used for the counting. 

(b) If the filter parameter is absent, the operation shall apply the 
filter constraint currently active in the notification channel when 
counting. If the alarmAckState constraint is present, the operation 
shall apply that constraint as well. 


status 


M 


ENUM 

(OperationSucceeded, 

OperationFailed) 


If allAlarmInf ormationCounted is true, status = 
OperationSucceeded. 

If operation_failed is true, status = OperationFailed. 



6.4.1.4 Pre-condition 

There are no pre-conditions. 



6.4.1.5 



Post-condition 



allAlarmInf ormationCounted. 



Assertion Name 



Definition 



allAlarmInf orm 
ationCounted 



All Alarmlnf ormation that satisfy the constraints expressed in input parameters filter and 
alarmAckState and are present in the AlarmLi st at the moment of this operation invocation 
are counted and the result returned. 

All Alarmlnf ormation in AlarmList remains unchanged as the result of this operation. 
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6.4.1.6 



Exceptions 



Name 


Definition 


ope rat ion_f ailed 


Condition: the pre-condition is false or the post-condition is true. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.5 



Interface AlarmIRP0peration_3 



6.5.1 unacknowledgeAlarms (O) 



6.5.1.1 



Definition 



IRPManager invokes this operation to remove acknowledgement information kept in one or more 

Alarmlnf ormation instances. 



6.5.1.2 



Input Parameters 



Name 


Quali 
tier 


Information Type 


Comment 


alarm 

InformationRe 

ferenceList 


M 


List of 

Alarmlnf ormation . al 
armid 


It carries one or more identifiers identifying 

Alarmlnf ormation in AlarmList. 


ackUserld 


M 


Alarmlnf ormation . ack 
Userld 


It identities the user that invokes this operation. 


ackSystemId 


O 


Alarmlnf ormation . ack 
Systemid 


It identifies the processing system on which the subject 
IRPManager runs. 



6.5.1.3 



Output Parameters 



Name 


Qual 
ifier 


Matching Information 


Comment 


badAlarmlnfor 
mationRef eren 
ceList 


M 


List of pair of 

Alarmlnf ormation . alar 
mid and the failure reason. 


If allAlarmsUnacknowledged is true, it contains 
no information. 

If someAlarmUnacknowledged is true, then it 
contains identifications of Alarmlnf ormation that 
are 

(a) present in input parameter 

Alarmlnf ormationReferenceList but are 
absent in the AlarmList ; or 

(b) present in input parameter 

Alarmlnf ormationReferenceList and are 
present in the AlarmList but the Acknowledgement 
Information (see note below table) has not changed, in 
contrast to IRPManager's request. 


status 


M 


ENUM (OperationSucceeded, 

OperationFailed, 

OperationPartiallySucceeded) 


If someAlarmUnacknowledged is true, status = 
Operation? artiallySuceeded. 

If allAlarmsUnacknowledged is true, status = 
OperationSucceeded. 

If operation_failed is true, status = OperationFailed. 
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Note: Acknowledgement Information is defined as the information contained in Alarmlnf ormat ion . ackTime, 
Alarmlnf ormation . ackUserld, Alarmlnf ormat on.ackSystemId and 
Alarmlnf ormation . ackState. 



6.5.1.4 



Pre-condition 



atLeastOneValidId AND validUserld&Systemld. 



Assertion Name 



Definition 



at Least OneVali 
did 



The Alarmlnf ormationReferenceList contains at least one identifier that identifies 
one Alarmlnf ormation in AlarmList and that this identified Alarmlnf ormation 
shall have its ackState indicating "acknowledged". 



validUserld&Sy 
stemid 



The values of ackUserld and ackSystemId attributes of the Alarmlnf ormation must 
be the same as the ones provided as input parameters. The Alarmlnf ormation is identified 
by the input parameter Alarmlnf ormationReferenceList. 



6.5.1.5 



Post-condition 



someAlarmUnacknowledged OR allAlarmsUnacknowledged. 



Assertion Name 


Definition 


someAlarmUnack 
nowledged 


At least one but not all Alarmlnf ormation identified in input parameter 
alarmListRef erenceList has been unacknowledged. This means that the ackState 
attribute has been set to "unacknowledged", that ackTime, ackUserld, ackSystemId attributes of 
this Alarmlnf ormation have been set to containing no information. 


allAlarmsUnack 
nowledged 


All Alarmlnf ormation identified in input parameter have been unacknowledged. This 
means that the ackState attribute has been set to "unacknowledged", that ackTime, ackUserld, 
ackSystemId attributes of this Alarmlnf ormation have been set to contain no information. 



6.5.1.6 



Exceptions 



Name 


Definition 


ope rat ion_f ailed 


Condition: Pre-condition is false or post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.6 



Interface AlarmIRP0peration_4 



6.6.1 setComment (O) 

6.6.1.1 Definition 

The IRPManager invokes this operation to record a comment in one or more Alarmlnf ormation instances in 
AlarmList. 
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6.6.1.2 Input Parameters 



Name 


Quali 
fier 


Information Type 


Comment 


Alarmlnformation 
Ref erenceList 


M 


List of 

Alarmlnformation . alarmld 


It carries one or more identifiers 
identifying Alarmlnformation 
instances in the AlarmList. 


commentUserld 


M 


The Comment. commentUserld where 
Comment is involved in relation- 

Alarmlnformation-Comment with 

an Alarmlnformation. 




comment Systemid 


O 


The Comment . commentSystemId 
where Comment is involved in 

relation-AlarmIn format ion- 
Comment with an 
Alarmlnformation. 




commentText 


M 


The comment. commentText where 
Comment is involved in relation- 

Alarmlnformation-Comment with 
an Alarmlnformation. 





6.6.1.3 Output Parameter 



Name 


Quali 
fier 


Matching Information 


Comment 


badAlarm 

Information 

ReferenceList 


M 


List of pair of 

Alarmlnformation . ala 
rmid and the failure reason. 


If allUpdated is true, it contains no information. 

If someUpdated is true, then it contains 
identifications of Alarmlnformation that are 
not present in AlarmList or that they are 
present, but Alarmlnformation. comments 
has not changed, in contrast to IRPManager's 
request. 


Status 


M 


ENUM( 

Operation succeeded. 
Operation failed. 
Operation partially failed) 


If allUpdated is true, then status = 
OperationSsucceeded. 

If someUpdated is true, then status = 
OperationPartiallyFailed. 

If exception operationFailed is raised, then status = 
OperationFailed. 



6.6.1.4 Pre-condition 

atLeastOneValidId . 



Assertion Name 



Properties 



atLeastOneValid 
Id 



The AlarmlnformationRef erenceList contains at least one identifier that identifies 

one Alarmlnformation in AlarmList. 
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6.6.1.5 



Post-condition 



allUpdated OR someUpdated. 



Assertion Name 


Properties 


allUpdated 


The Alarmlnf ormat ion . comment of all alarms identified by the input parameter 
AlarmlnformationReferenceList has been updated. 

The input parameter commentText, commentUserld and commentSystemId are 
added to the Alarmlnf ormation . comment. The time of the operation invocation is 
captured in the Alarmlnf ormation. comment as well. 

To make it possible to add the new comment, the IRP Agent may remove one or more old 
comment previously held by Alarmlnf ormation . comments. 


someUpdated 


The Alarmlnf ormat ion. comment attribute of at least one but not all alarms identified by 

the input parameter AlarmlnformationReferenceList has been updated. 

The input parameter commentText, commentUserld and commentSystemId are 
added to the Alarmlnf ormation . comment. The time of the operation invocation is 
captured in the Alarmlnf ormation . comment as well. 

To add a new Comment, it may be necessary to remove one or more old Comment instances 
being held. The commentTime of the removed Comment instances shall be older than that 
of the remaining Comment instances. 



6.6.1.6 



Exceptions 



Name 



Properties 



ope rat ion_f ailed 



Condition: the pre-condition is false or the post-condition is false. 
Returned Information: The output parameter status. 
Exit state: Entry state. 



6.7 



Interface AlarmlRPNotifications 1 



This specification does not specify methods for IRPManager to detect alarm loss. The use of alarmld to detect alarm 
loss is an arrangement made between IRP Agent and IRPManager. This arrangement is outside the scope of this 
specification. For example, IRPAgent may use integer sequence (e.g. 1, 2, 3, 4, 5, ...) as alarmld instances 
for its alarms. Based on this knowledge, IRPManager can detect alarm loss. This kind of arrangement may not be 
possible for all SS. 

This specification does not specify how IRPAgent can determine if IRPManager has received alarms correctly. Not 
all SSs provide such capability. 

This document does not specify methods for IRPManager and IRPAgent to recover alarm loss. The only 
mechanism recommended to deal with alarm loss is the use of getAlarmList operation. This document does not 
specify conditions under which IRPManager should invoke this operation. 



6.7.1 



notifyNewAlarm (M) 



6.7.1.1 



Definition 



Anew Alarmlnformation has been added in the Ala rmList. The subscribed IRPManager instances are 
notified of this fact if the added Alarmlnformation satisfies the current filter constraint of their subscription. 
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6.7.1.2 



Input Parameters 



Parameter Name 


Quali 
fier 


Matching Information 


Comment 


ob jectClass 


M,F 


Monit or edEnt it y.ob jectClass 
where the MonitoredEntity is 
identified by the r elation- 
Ala rmedOb ject - 
Alarmlnf ormation of the new 
Alarmln format ion. 




ob jectlnstance 


M,F 


Monit or edEnt it y.ob ject Inst a 
nee where the MonitoredEntity 
is identified by the relation- 
Ala rmedOb ject - 
Alarmlnf ormation of the new 
Alarmlnf ormation. 




notif icationid 


M 


This carries the semantics of 
notification identifier. 




eventTime 


M,F 


Alarmlnf ormation . alarmRais 
edTime 




systemDN 


C,F 


IRPAgent. systemDN where the 
IRPAgent is related to the 
AlarmlRP that is related to this 

AlarmList. 


It carries the DN of the IRPAgent. 


notificationType 


M,F 


"notif yNewAlarm". 




probableCause 


M,F 


Alarmlnf ormation . probableC 
ause 




perceivedSeverity 


M,F 


Alarmlnf ormation . perceived 
Severity 




alarm! ype 


M,F 


Alarmlnf ormation . eventType 




specif icProblem 





Alarmlnf ormation . specif icP 
roblem 




correlatedNotificat 
ions 





The set of 

CorrelatedNotificat ion 
related to this Alarmlnf ormation. 




backedUpStatus 





Alarmlnf ormation. backedUpSt 
atus 




backUpOb ject 





Monit oredEntity.ob ject Inst a 

nee where the MonitoredEntity 

is identified byrelation- 

BackUpObject- 

Alarmlnf ormation of the new 

Alarmln format ion. 


It carries the DN of the back up object. 


trendlndication 





Alarmlnf ormation .trendlndi 
cation 




thresholdlnfo 





Alarmlnf ormation .threshold 
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Parameter Name 


Quali 
fier 


Matching Information 


Comment 






Info 




stateChangeDef initi 
on 


O 


Alarmln format ion. state Chan 
ge 




monitoredAttributes 


O 


Alarmlnformat ion. monitored 
Attributes 




proposedRepair Actio 
ns 


o 


Alarmlnformaton.proposedRepair 

Actions 




additional Text 


o 


Alarmln format ion. additiona 
IText 




alarmld 


M 


Alarmlnformat ion. alarmld 





6.7.1.3 Triggering Event 

6.7.1.3.1 From-state 



noMatchedAlarm. 



Assertion Name 



Definition 



noMatchedAlarm 



AlarmList does not contain an Alarmlnf ormation that has the following properties: 

• Its matching-criteria-attributes values are identical to that of the newly generated network 
alarm and 

• It is involved in relation-AlarmObject-AlarmInf ormation with the same 
MonitoredEntity as the one identified by the newly generated network alarm. 



6.7.1.3.2 



To-state 



newAlarmlnAlarmList . 



Assertion Name 



Definition 



newAlarmlnAlar 
mList 



AlarmList contains an Alarmlnf ormation holding information conveyed by the newly 
generated network alarm. This Alarmlnf ormation is involved in relation- 
AlarmObject-Alarmlnf ormation with the same MonitoredEntity as the one 
identified by the newly generated network alarm. 

The following attributes of the Alarmlnf ormation shall be populated with information in 
the newly generated alarm. 

alarmld, notif icationid, alarmRaisedTime, eventType, 
probableCause, perceivedSeverity . 

The following attributes of the same Alarmlnf ormation shall be populated with 
information in the newly generated alarm if the information is present (in the newly generated 
alarm) and if the attribute is supported. 

specif icProblem, backedUpStatus, trendlndication, 
thresholdinf o, stateChangedDef inition, monitoredAttributes, 
proposedRepairActions, additionalText . 
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6.7.2 notifyAckStateChanged (M) 



6.7.2.1 



Definition 



The subscribed IRPManager instances are notified regarding changes in alarm Acknowledgement State. The 
Alarmlnf ormation carried in the notification shall satisfy the current filter constraint of the subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 



6.7.2.2 



Input Parameters 



Parameter Name 


Quali 
fier 


Matching Information 


Comment 


ob jectClass 


M,F 


MonitoredEntity.ob jectClass where the 
MonitoredEntity is identified by the relation- 

AlarmedObject-Alarmlnf ormation of the 
Alarmlnf ormation. 




ob jectlnstance 


M,F 


MonitoredEntity.ob jectlnstance where the 
MonitoredEntity is identified by the relation- 

AlarmedObject-Alarmlnf ormation of the 
Alarmlnf ormation. 




notif icationid 


M 


This caiTies the semantics of notification identifier. 




eventTime 


M,F 


Alarmlnf ormation . ackTime 




systemDN 


C,F 


IRPAgent. systemDN 




notificationType 


M,F 


"notifyAckStateChanged" 




probableCause 


M,F 


Alarmlnf ormation .probableCause 




perceived Severity 


M,F 


Alarmln format ion. perceivedSever it y 




alarmType 


M,F 


Alarmlnf ormation . eventType 




alarmld 


M 


Alarmlnf ormation . alarmld 




ackTime 


M 


Alarmlnf ormation . ackTime 




ackState 


M 


Alarmlnf ormation . ackState 




ackUserld 


M 


Alarmlnf ormation . ackUserld 




ackSystemId 


O 


Alarmln format ion. ackSystemId 





6.7.2.3 



Triggering Event 



6.7.2.3.1 



From-state 



alarmlnf ormationExists . 



Assertion Name 


Definition 


alarmln format lonExists 


The Alarmlnf ormation exists in AlarmList. 
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6.7.2.3.2 To-state 

alarmAckStateHasChanged . 



Assertion Name 


Definition 


alarmAckStateHasChanged 


The Alarmlnf ormation . ackState of the Alarmlnf ormation 
identified by from-state assertion alarmlnf ormationExists have 
been updated. Specifically, the following attributes of the subject 
Alarmlnf ormation are updated. 

notif icationid, ackTime, ackUserld, ackState, 
ackSystemld. 



6.7.3 notif yClearedAlarm (M) 



6.7.3.1 



Definition 



IRP Agent notifies The subscribed IRPManager is notified of alarm clearing if the subject Alarmlnf ormation 
satisfies the optional filter constraint expressed in the subscribe operation. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 



6.7.3.2 



Input Parameters 



Parameter Name 


Qualifi 
er 


Matching Information 


Comment 


ob jectClass 


M,F 


Monit oredEnt it y.ob jectClass where 
the MonitoredEntity is identified by the 

relation-AlarmedOb ject- 
Alarmlnf ormation of the new 
Alarmlnformation. 




objectlnstance 


M,F 


Monit oredEnt it y.ob ject Instance 
where the MonitoredEntity is identified by 
the relation-AlarmedOb ject- 
Alarmlnf ormation of the new 
Alarmlnformation. 




notif icationid 


M 


This carries the semantics of notification 
identifier. 




eventTime 


M,F 


Alarmlnformation . alarmClearedTime 




systemDN 


C,F 


IRP Agent. systemDN where the IRP Agent 
is related to the AlarmlRP that is related to this 

AlarmList. 




notif IcationType 


M,F 


"not if yClearedAlarm" 




probableCause 


M,F 


Alarmlnformation .probableCause 




perceivedSeverity 


M,F 


Alarmlnformation .perceivedSeverit 

y 


Its value shall indicate 

Cleared. 


alarmType 


M,F 


Alarmlnformation . eventType 




correlated 
Notifications 


O 


The set of CorrelatedNoti float ion 


It contains references to other 

Alarmlnformation 
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Parameter Name 


Qualifi 
er 


Matching Information 


Comment 






related to this Alarmlnf ormation. 


instances whose 
perceivedSeverity 
levels are Cleared as well. 
In this way, 

perceivedSeverity 
level of multiple 
Alarmlnf ormation 
instances can be Cleared 
by one notification. 


alarmld 


M 


Alarmlnf ormation . alarmld 





6.7.3.3 



Triggering Event 



6.7.3.3.1 From-state 

alarmMatched AND alarmCleared. 



Assertion Name 


Definition 


alarmMatched 


The matching-criteria-attributes of the newly generated network alarm have values that are 
identical (matched) with ones in one Alarmlnf ormation in AlarmList and the 
perceivedSeverity of the matched Alarmlnformation is not Cleared. 


alarmCleared 


The perceivedSeverity of the newly generated network alarm is Cleared. 



6.7.3.3.1 To-state 

Alarmlnf ormationCleared_l - 



Assertion Name 


Definition 


Alarmlnf ormationC 
leared_l 


The following attributes of the subject Alarmlnformation are updated. 

perceivedSeverity (updated to Cleared) , alarmClearedTime. 



6.7.4 



6.7.4.1 



notifyAlarmListRebuilt (M) 



Definition 



The IRP Agent or its related AlarmlRP maintains an AlarmList. They can lose confidence in the integrity of its 
AlarmList. Under this condition, IRP Agent or its related AlarmlRP or the related AlarmList shall invoke 
notifyAlarmListRebuilt notification after the AlarmList has been rebuilt. 

The IRP Agent can also invoke notifyAlarmListRebuilt notification indicating that part of the AlarmList 
has been rebuilt. In this case, the notification carries the managed object (MO) instance indicating that the 
AlarmList only have been rebuilt for alarms concerning this MO and its subordinate MOs. Furthermore, this 
notification indicates that there is no rebuilt going on for superior MOs of this MO. 
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6.7.4.2 Input Parameters 



Parameter Name 


Qualifi 
er 


Matching Information 


Comment 


ob jectClass 


M,F 


It carries the 

IRP Agent. object Class 
or alternatively, the object 
class of another MO. 


If it carries the IRP Agent. objectClass, then all 
Alarmlnformation instances in the AlarmList 
may have been rebuilt. 

If it carries the object class of another MO, then 
all Alarmlnformation instances related to the 
MO and its subordinate MOs may have been 
rebuilt. The Alarmlnformation instances not 
related to the subject MO and its subordinate 
MOs ai-e not subject to rebuilt. 


object Instance 


M,F 


It carries the 

IRPAgent.iRPAgentldor 
alternatively, the id of another 
MO. 


If objectClass carries the 
IRP Agent. objectClass, then this parameter 
carries the RDN of the IRPAgent whose 
AlarmList has been rebuilt. 

If objectClass carries the object class of 
another MO, then this parameter carries the 
RDN of the MO instance indicating that the 
Ala rmL i s t only have been rebuilt for alarms 
concerning that MO and its subordinate MOs. 


notification Id 


M 


This carries the semantics of 
notification identifier. 




eventlime 


M,F 


It carries the time when the 
IRP Agent has rebuilt the 
AlarmList successfully. 




systemDN 


C,F 


IRP Agent. systemDN 
where the IRPAgent is 
related to the AlarmlRP that 
is related to this AlarmList. 




notificationlype 


M,F 


"notif yAlarmListRebu 
lit". 




reason 


M 


"indeterminate". Other values 
can be added. 


It carries the reason why the IRPAgent has 
rebuilt the AlarmList. 



6.7.4.3 



Triggering Event 



6.7.4.3.1 From-state 

alarmListRebuilt . 



Assertion Name 


Definition 


alarmListRebuilt 


IRPAgent loses confidence in part or whole of its AlarmList. IRPAgent has 
initiated procedure to repair its AlarmList. 



6.7.4.3.2 To-state 

alarmListRebuilt 2. 
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Assertion Name 


Definition 


alarmListRebuilt_2 


IRPAgent rebuilt the whole or part of AlarmList. 



6.8 



Interface AlarmlRPNotification 2 



6.8.1 



notif yChangedAlarm (O) 



6.8.1.1 



Definition 



The subscribed IRPManager instances are notified regarding changes in Alarmlnf ormation in AlarmList. 
This notification is only triggered by a change in perceivedSeverity attribute value (except to the value 
"Cleared"). The Alarmlnf ormation carried in the notification shall satisfy the current filter constraint of the 
subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 



6.8.1.2 



Input Parameters 



Parameter Name 


Qua 
lifier 


Matching Information 


Comment 


ob jectClass 


M,F 


MonitoredEntity.ob jectClass where the 
MonitoredEntity is identified by the relation- 
AlarmedObject-Alarmlnf ormation of the new 
Alarmln format ion. 




ob jectlnstance 


M,F 


MonitoredEntity.ob jectlnstance where the 
MonitoredEntity is identified by the relation- 
AlarmedOb ject-Alarmlnformation of the new 
Alarmlnf ormation. 




notif icationid 


M 


This carries the semantics of notification identifier. 




eventTime 


M,F 


Alarmlnf ormation . alarmChangedTime 




systemDN 


C,F 


IRPAgent. systemDN where the IRPAgent is 
related to the AlarmlRP that is related to this 

AlarmList. 




notif IcationType 


M,F 


"not if yChangedAlarm" 




probableCause 


M,F 


Alarmln format ion. probableCause 




perceivedSeverity 


M,F 


Alarmln format ion. perceivedSeverity 




alarmType 


M,F 


Alarmlnf ormation . eventType 




alarmld 


M 


Alarmlnf ormation .alarmld 
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6.8.1.3 



Triggering Event 



6.8.1.3.1 From-state 

alarmMatched AND alarmNotCleared AND alarmChanged. 



Assertion Name 


Definition 


alarmMatched 


The matching-criteria-attributes of the newly generated network alai^m has values that are 
identical (matches) with ones in one Alarmlnf ormation in AlarmList. 


alarmNotCleared 


The perceivedSeverity of the newly generated network alarm is not Cleared. 


alarmChanged 


The perceivedSeverity of the newly generated network alarm and of the matched 

Alarmlnf ormation are different. 



6.8.1.3.2 



To-state 



inf ormationUpdate . 



Assertion Name 



Definition 



inf ormationUpd 
ate 



• The Alarmlnf ormation identified in alarmMatched in from-state has been 

updated according to the following rules : perceivedSeverity is updated; 

• notificationid is updated; 

• alarmChangedTime is updated; 

• ackTime, ackUserld and ackSystemId are updated to contain no information; 

• ackState is updated to "unacknowledged"; 



6.9 



Interface AlarmlRPNotification 3 



6.9.1 notif yComments (O) 



6.9.1.1 



Definition 



The subscribed IRPManager instances are notified regarding to the addition of Comment , as a consequence of 
successful completion of setComment operation, in Alarmlnf ormation instances in AlarmList. The 
Alarmlnf ormation carried in the notification shall satisfy the current filter constraint of the subscription. 

The notification shall contain all parameters that are filterable and are present in the original (related) 

notif yNewAlarm notification. 

IRPAgent shall support this notification if it supports the operation setComment. 
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6.9.1.2 



Input Parameters 



Parameter Name 


Quali 
fier 


Matching Information 


Comment 


ob jectClass 


M,F 


MonitoredEntity.ob jectClass where the 
MonitoredEntity is identified by the relation- 

AlarmedOb ject-AlarmInf ormation of the 
Alarmln format ion. 




ob jectlnstance 


M,F 


MonitoredEntity.ob jectlnstance where the 
MonitoredEntity is identified by the relation- 

AlarmedObject-Alarmlnf ormation of the 
Alarmln format ion. 




notificationid 


M 


This carries the semantics of notification identifier. 




eventTime 


M,F 


Alarmlnf ormation . alarmChangedTime 




systemDN 


C,F 


IRPAgent. systemDN 




notif icationType 


M,F 


"notif yComments" 




alarm! ype 


M,F 


Alarmlnf ormation . eventType 




probableCause 


M,F 


Alarmln format ion. probableCause 




perceived Severity 


M,F 


Alarmlnf ormation . perceivedSeverity 




comments 


M 


The set of Comment instances involved in relationship with 
this Alarmlnf ormation. 




alarmld 


M 


Alarmlnf ormation . alarmld 





6.9.1.3 



Triggering Events 



6.9.1.3.1 



From-state 



alarmlnf ormationExists . 



Assertion Name 


Definition 


alarmlnf ormationExists 


The Alarmlnf ormation is in AlarmList. 



6.9.1.3.2 



To-state 



comment Inserted. 



Assertion Name 


Definition 


comment Inserted 


One Comment has been created and it is involved in a relationship with the 
Alarmlnf ormation identified by from-state assertion 
alarmlnformationExists. The following attributes of the newly 
created Comment shall be populated. 

commentTime (set to setComment operation completion time), 

commentText, commentUserld and commentSystemld. 
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Annex A (normative): 
Event Types 

This appendix lists and explains event types used by this document. 

Event type is defined in 3GPP TS 32.302 [5]. The table below lists some of the event types referred to in this 
document. 

Notification IRP: Information Service [5] defines a parameter called notif icationType that shall be present in all 
notification. This document defines a parameter called alarmType that shall be present in all notifications carrying 
alarm information. Examples of the notif icationType are "notification of new alarm", "notification of AlarmList 
rebuilt", "notification of alarm cleared", etc. Examples of the alarmType are the event types defined in table below. 

This document also defines an attribute of Alarmlnf ormation called eventType. The mapping of this 
eventType (internal attribute and not visible to IRPManager) to notif icationType or alarmType (both 
visible to IRPManager) is defined in relevant sections of this document. The choice of using "eventType" is to 
keep the list of attributes of AlarmList unchanged (compared to Release 99). One can replace this eventType 
with two attributes, called notif icationType and alarmType so that mapping of these two attributes to the 
externally visible parameters of the same name will be straight-forward. 

It is noted that the Alarmlnf ormation. eventType can capture more information than the ITU-T defined event 
types [2]. One example is "notification of alarm list rebuilt". 

It is noted that the mapping of the IS notif icationType and alarmType to CMIP's event type or CORBA 
event_name or other fields are specified in the respective SS documents. 



TableA.l: Event Types 



Event Types 



Explanation 



Communications Alarm 



An alarm of this type is associated with the procedure and/or process required conveying information from 
one point to another (ITU-T Recommendation X.733 [2]). 



Processing Error Alarm 



An alarm of this type is associated with a software or processing fault (ITU-T Recommendation X.733 [2]). 



Environmental Alarm 



An alarm of this type is associated with a condition related to an enclosure in which the equipment resides 
(ITU-T Recommendation X.733 [2]). 



Quality of Service Alarm 



An alarm of this type is associated with degradation in the quality of a service (ITU-T Recommendation 

X.733 [2]). 



Equipment Alarm 



An alarm of this type is associated with an equipment fault (ITU-T Recommendation X.733 [2]). 
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Annex B (normative): 
Probable Causes 



This appendix lists probable causes and their corresponding event types. 

Sources of these probable causes are ITU-T Recommendation M.3100 [11], ITU-T Recommendation X. 721 [3], ITU-T 
Recommendation X.733 [2], ITU-T Recommendation X.736 [15] and GSM 12.1 1 [4]. 

The list may be extended in the future, e.g. with UMTS-specific probable causes. 

Table B.l: Probable Causes from ITU-T Recommendation M.3100 [11] 



M.3100 Probable cause 


Event type 


Indeterminate 


Unknown 


Alarm Indication Signal (AIS) 


Communications 


Call Setup Failure 


Communications 


Degraded Signal 


Communications 


Far End Receiver Failure (FERF) 


Communications 


Framing Error 


Communications 


Loss Of Frame (LOF) 


Communications 


Loss Of Pointer (LOP) 


Communications 


Loss Of Signal (LOS) 


Communications 


Payload Type Mismatch 


Communications 


Transmission Error 


Communications 


Remote Alarm Interface 


Communications 


Excessive Bit Error Rate (EBER) 


Communications 


Path Trace Mismatch 


Communications 


Unavailable 


Communications 


Signal Label Mismatch 


Communications 


Loss Of Multi Frame 


Communications 


Back Plane Failure 


Equipment 


Data Set Problem 


Equipment 


Equipment Identifier Duplication 


Equipment 


External IF Device Problem 


Equipment 


Line Card Problem 


Equipment 


Multiplexer Problem 


Equipment 


NE Identifier Duplication 


Equipment 


Power Problem 


Equipment 


Processor Problem 


Equipment 


Protection Path Failure 


Equipment 


Receiver Failure 


Equipment 


Replaceable Unit Missing 


Equipment 


Replaceable Unit Type Mismatch 


Equipment 


Synchronisation Source Mismatch 


Equipment 


Terminal Problem 


Equipment 


Timing Problem 


Equipment 


Transmitter Failure 


Equipment 


Trunk Card Problem 


Equipment 


Replaceable Unit Problem 


Equipment 


Air Compressor Failure 


Environmental 


Air Conditioning Failure 


Environmental 


Air Dryer Failure 


Environmental 


Battery Discharging 


Environmental 


Battery Failure 


Environmental 


Commercial Power Failure 


Environmental 


Cooling Fan Failure 


Environmental 


Engine Failure 


Environmental 


Fire Detector Failure 


Environmental 


Fuse Failure 


Environmental 


Generator Failure 


Environmental 


Low Battery Threshold 


Environmental 


Pump Failure 


Environmental 
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M.3100 Probable cause 


Event type 


Rectifier Failure 


Environmental 


Rectifier Higii Voltage 


Environmental 


Rectifier Low F Voltage 


Environmental 


Ventilation System Failure 


Environmental 


Enclosure Door Open 


Environmental 


Explosive Gas 


Environmental 


Fire 


Environmental 


Flood 


Environmental 


High Humidity 


Environmental 


High Temperature 


Environmental 


High Wind 


Environmental 


Ice Build Up 


Environmental 


Intrusion Detection 


Environmental 


Low Fuel 


Environmental 


Low Humidity 


Environmental 


Low Cable Pressure 


Environmental 


Low Temperature 


Environmental 


Low Water 


Environmental 


Smoke 


Environmental 


Toxic Gas 


Environmental 


Storage Capacity Problem 


Processing error 


Memory Mismatch 


Processing error 


Corrupt Data 


Processing error 


Out Of CPU Cycles 


Processing error 


Software Environment Problem 


Processing error 


Software Download Failure 


Processing error 



Table B.2: Probable Causes from ITU-T Recommendation X.721 [3] / ITU-T Recommendation X.733 [2] 



X.733 Probable Cause 


Event type 


Adapter Error 


Equipment 


Application Subsystem Failure 


Processing error 


Bandwidth Reduction 


Quality of service 


Call Establishment Error 


Communications 


Communication Protocol Error 


Communications 


Communication Subsystem Failure 


Communications 


Configuration or Customizing Error 


Processing error 


Congestion 


Quality of service 


Corrupt Data 


Processing error 


CPU Cycles Limit Exceeded 


Processing error 


Data Set or Modem Error 


Equipment 


Degraded Signal 


Communications 


DTE-DCE Interface Error 


Communications 


Enclosure Door Open 


Environmental 


Equipment Malfunction 


Equipment 


Excessive Vibration 


Environmental 


File Error 


Processing error 


Fire Detected 


Environmental 


Flood Detected 


Environmental 


Framing Error 


Communications 


Heating or Ventilation or Cooling System Problem 


Environmental 


Humidity Unacceptable 


Environmental 


Input/Output Device Error 


Equipment 


Input Device Error 


Equipment 


LAN Error 


Communications 


Leak Detection 


Environmental 


Local Node Transmission Error 


Communications 


Loss of Frame 


Communications 


Loss of Signal 


Communications 


Material Supply Exhausted 


Environmental 


Multiplexer Problem 


Equipment 


Out of Memory 


Processing error 


Output Device Error 


Equipment 


Performance Degraded 


Quality of service 
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X.733 Probable Cause 


Event type 


Power Problem 


Equipment 


Pressure Unacceptable 


Environmental 


Processor Problem 


Equipment 


Pump Failure 


Environmental 


Queue Size Exceeded 


Quality of service 


Receive Failure 


Equipment 


Receiver Failure 


Equipment 


Remote Node Transmission Error 


Communications 


Resource at or Nearing Capacity 


Quality of service 


Response Time Excessive 


Quality of service 


Re-transmission Rate Excessive 


Quality of service 


Software Error 


Processing error 


Software Program Abnormally Terminated 


Processing error 


Software Program Error 


Processing error 


Storage Capacity Problem 


Processing error 


Temperature Unacceptable 


Environmental 


Threshold Crossed 


Quality of service 


Timing Problem 


Equipment 


Toxic Leak Detected 


Environmental 


Transmit Failure 


Equipment 


Transmitter Failure 


Equipment 


Underlying Resource Unavailable 


Processing error 


Version Mismatch 


Processing error 



Table B.3: Probable Causes from GSM 12.11 [4] 



GSM 12.11 Probable Cause 


Event Type 


A-bis to BTS interface failure 


Equipment 


A-bis to TRX interface failure 


Equipment 


Antenna problem 


Equipment 


Battery breakdown 


Equipment 


Battery charging fault 


Equipment 


Clock synchronisation problem 


Equipment 


Combiner problem 


Equipment 


Disk problem 


Equipment 


Equipment failure 


Equipment 


Excessive receiver temperature 


Equipment 


Excessive transmitter output power 


Equipment 


Excessive transmitter temperature 


Equipment 


Frequency hopping degraded 


Equipment 


Frequency hopping failure 


Equipment 


Frequency redefinition failed 


Equipment 


Line interface failure 


Equipment 


Link failure 


Equipment 


Loss of synchronisation 


Equipment 


Lost redundancy 


Equipment 


Mains breakdown with battery back-up 


Equipment 


Mains breakdown without battery back-up 


Equipment 


Power supply failure 


Equipment 


Receiver antenna fault 


Equipment 


Receiver Failure 


Equipment 


Receiver multicoupler failure 


Equipment 


Reduced transmitter output power 


Equipment 


Signal quality evaluation fault 


Equipment 


Timeslot hardware failure 


Equipment 


Transceiver problem 


Equipment 


Transcoder problem 


Equipment 


Transcoder or rate adapter problem 


Equipment 


Transmitter antenna failure 


Equipment 


Transmitter antenna not adjusted 


Equipment 


Transmitter failure 


Equipment 


Transmitter low voltage or current 


Equipment 


Transmitter off frequency 


Equipment 
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GSM 12.11 Probable Cause 



Event Type 



Database inconsistency 



Processing error 



File system call unsuccessful 



Processing error 



Input parameter out of range 



Processing error 



Invalid parameter 



Processing error 



Invalid pointer 



Processing error 



Message not expected 



Processing error 



Message not initialised 



Processing error 



Message out of sequence 



Processing error 



System call unsuccessful 



Processing error 



Timeout expired 



Processing error 



Variable out of range 



Watch dog timer expired 
Cooling system failure 



Processing error 



Processing error 



Environmental 



External equipment failure 



Environmental 



External power supply failure 



Environmental 



External transmission device failure 



Environmental 



Fan failure 



Environmental 



High humidity 



Environmental 



High temperature 



Environmental 



Intrusion detected 



Environmental 



Low humidity 



Environmental 



Low temperature 



Environmental 



Smoke detected 



Environmental 



Excessive Error Rate 



Quality of service 



Reduced alarm reporting 



Quality of service 



Reduced event reporting 



Quality of service 



Reduced logging capability 



Quality of service 



System resources overload 



Quality of service 



Broadcast channel failure 



Communications 



Connection establishment error 



Communications 



Invalid message received 



Communications 



Invalid MSU received 



Communications 



LAPD link protocol failure 



Communications 



Local alarm indication 



Communications 



Remote alarm indication 



Communications 



Routing failure 



Communications 



SS7 protocol failure 



Communications 



Transmission error 



Communications 
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Table 20 identifies probable causes that are defined by more than one standard. This is for information only. 

Table B.4: Duplicated Probable Causes 



Duplicated Probable Cause 


GSM 12.11 


X.721 X.733 


M.3100 


Event Type 


Call Establishment Failure (X.721/X.733) 
Call Setup Failure (M.3100) 




X 


X 


Communications 


Degraded Signal 




X 


X 


Communications 


Framing Error 




X 


X 


Communications 


Loss of Frame 




X 


X 


Communications 


Loss of Signal 




X 


X 


Communications 


Equipment Failure (GSM 12.11) 
Equipment Malfunction (X.721/X.733) 


X 


X 




Equipment 


Multiplexer Problem 




X 


X 


Equipment 


Power Problem 




X 


X 


Equipment 


Processor Problem 




X 


X 


Equipment 


Receiver Failure 


X 


X 


X 


Equipment 


Timing Problem 




X 


X 


Equipment 


Transmitter Failure 


X 


X 


X 


Equipment 


Enclosure Door Open 




X 


X 


Environmental 


Fan Failure (GSM 12.11) 
Cooling Fan Failure (M.3100) 


X 




X 


Environmental 


Fire Detected (X.721/X.733) 
Fire (M.3100) 




X 


X 


Environmental 


Flood Detected (X.721/X.733) 
Flood (M.3100) 




X 


X 


Environmental 


High Humidity 


X 




X 


Environmental 


High Temperature 


X 




X 


Environmental 


Intrusion Detected (GSM 12.11) 
Intrusion Detection (X.736/M.3100) 


X 




X 


Environmental 


Low Humidity 


X 




X 


Environmental 


Low Temperature 


X 




X 


Environmental 


Pump Failure 




X 


X 


Environmental 


Smoke Detected (GSM 12.11) 
Smoke (M.3100) 


X 




X 


Environmental 


Storage Capacity Problem 




X 


X 


Processing Error 


Excessive Bit Error Rate (M.3100) 
Excessive Error Rate (GSM 12. 11) 


X 




X 




Corrupt Data 




X 


X 


Processing Error 
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Annex C (informative): 

Examples of using notifyChangedAlarm 

This annex describes a number of valid and invalid interactions governing the case when IRP Agent is reporting a 
specific fault of a particular network resource whose alarm severity level changes from, e.g. "Critical" to "Minor" and 
then to "Cleared". 

In the following examples: 

ni is notif icationid, 

moc is managedOb jectClass, 

moi is managedOb ject Instance, 

et is eventType, 

pc is probableCause, 

sp is specif icProblem, 

ps is perceivedSeverity and 

ai is alarmld. 

EXAMPLE 1 : Valid sequence 1 to support the hypothetical case: 

(1) Notif yNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 
(2) NotifyChangedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 
(3) Notif yClearedAlarm 

(ni=3, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 2: Valid sequence 2 to support the hypothetical case: 

(1) Notif yNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyClearedAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

(3) Notif yNewAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(4) NotifyClearedAlarm 

(ni=4, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 

EXAMPLE 3: Invalid sequence 1 to support the hypothetical case: 
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(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) Notif yChangedAlarm 

(ni=2, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

(3) NotifyClearedAlarm 

(ni=3, ai=Y, moc=A, moi=B, et=C, pc=D, sp=E, ps=Cleared) 
Interaction (2) is illegal since it uses a different ai for the same alarm. It should use ai=X as in interaction (1). 

EXAMPLE 4: Invalid sequence 2 to support the hypothetical case: 

(1) NotifyNewAlarm 

(ni=l, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Critical) 

(2) NotifyNewAlarm 

(ni=2, ai=X, moc=A, moi=B, et=C, pc=D, sp=E, ps=Minor) 

Interaction (2) is illegal since it invokes notifyNewAlarm using same ai value. It should use 

notif yChangedAlarm with the same ai value. 
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Annex D (informative): 
Change history 



Change history | 
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TSG# 


TSG Doc. 


CR 
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-- 


- 
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Split of TS - Part 2: Alarm Integration Reference Point (IRP): 
Information Service (IS) 


3.0.1 
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- 
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3.1.1 


3.2.0 
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3.2.0 


3.3.0 
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SP-000520 
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3.2.0 


3.3.0 
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SP-000520 


005 




Identification of valid Event Types and Extended Event Types 
within Notifications 
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3.3.0 
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3.2.0 


3.3.0 
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3.2.0 


3.3.0 
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008 
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3.3.1 
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